- 
                Notifications
    You must be signed in to change notification settings 
- Fork 421
Update to rust-bitcoin v0.30.2 #2740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this!
Seems tests are failing due to invalid PoWs in lightning-block-sync. I poked around a bit but couldn't immediately see what the issue is.
2930eb9    to
    8fc4764      
    Compare
  
    | Codecov ReportAttention:  
 ❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@            Coverage Diff             @@
##             main    #2740      +/-   ##
==========================================
- Coverage   88.55%   88.50%   -0.06%     
==========================================
  Files         113      113              
  Lines       89330    89323       -7     
  Branches    89330    89323       -7     
==========================================
- Hits        79110    79052      -58     
- Misses       7849     7896      +47     
- Partials     2371     2375       +4     ☔ View full report in Codecov by Sentry. | 
8fc4764    to
    768b975      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM from my side, I think.
Given the size of the changeset and its invasiveness having a second reviewer seems appropriate though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whew, LGTM. Good to squash if we want to fix check-commits.
768b975    to
    8220621      
    Compare
  
    | Squashed and found a way to drop one of the commits (wpaulino@9857df3). | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Someone feel free to land this after CI passes if I'm AFK, since @tnull also ack'd previously.
8220621    to
    6181985      
    Compare
  
    6181985    to
    ad56847      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! CI failure is unrelated, so I'm going ahead landing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Congrats on merging this! I took a look to see what we can improve in bitcoin and found some inspiration and also potential improvements on your side.
| let BlockHeaderData { chainwork, height, header } = data; | ||
| serde_json::json!({ | ||
| "chainwork": chainwork.to_string()["0x".len()..], | ||
| "chainwork": chainwork.to_be_bytes().as_hex().to_string(), | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI this could be format!("{:064x}", chainwork) which conveys the intent better.
| "nonce": header.nonce, | ||
| "bits": header.bits.to_hex(), | ||
| "previousblockhash": header.prev_blockhash.to_hex(), | ||
| "bits": header.bits.to_consensus().to_be_bytes().as_hex().to_string(), | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
format!("{08x}", header.bits.to_consensus()) would convey the meaning better but your code is actually faster because std formatting is over-complicated. I've opened an issue to support hex directly on CompactTarget but that will still be slower than your code.
| match WitnessProgram::new(*version, program.clone()) { | ||
| Ok(witness_program) => Payload::WitnessProgram(witness_program), | ||
| Err(_) => return None, | ||
| } | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So previously you'd accept invalid addresses but now you silently ignore them. Is this even correct? Maybe the error handling should be at creation of Fallback::SegWitProgram, so the variant should change to store WitnessProgram directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are parsing invoices provided by random scanning. We'd much rather succeed at parsing an invoice with invalid fallback addresses than ignore it, and better to provide some set of fallback addresses than nothing. That said, I'm pretty sure ~no one actually uses the fallback addresses in BOLT11, since unified QR codes via BIP 21 are a thing now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add an API to check if any are invalid so that an application can emit a warning in such case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given these things are basically unused, I'm not sure its worth any effort :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I think it should be at least be documented. I'd be pissed if a library silently dropped data even in edge cases.
| } | ||
| } | ||
| assert_eq!(base_weight + inputs_total_weight as usize, claim_tx.weight() + /* max_length_sig */ (73 * inputs_weight.len() - sum_actual_sigs)); | ||
| assert_eq!(base_weight + inputs_total_weight, claim_tx.weight().to_wu() + /* max_length_sig */ (73 * inputs_weight.len() as u64 - sum_actual_sigs)); | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this could be somehow replaced with predict_weight(https://docs.rs/bitcoin/latest/bitcoin/blockdata/transaction/fn.predict_weight.html) but the whole code is complicated so I'm not sure what it does.
Anyway, in general we want to avoid operations on raw integers so it might be nice to understand your use case better. Note that Weight doesn't impl Add precisely because it breaks naive implementations once there's more than 252 inputs/outputs. I don't see such handling in your code so you might have the same bug here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a few places where we'd benefit from a weight estimation/prediction API. Now that there's one in rust-bitcoin, we should definitely switch over, just didn't want to handle that in this PR.
| fn test_channel_id_v1_from_funding_txid() { | ||
| let channel_id = ChannelId::v1_from_funding_txid(&[2; 32], 1); | ||
| assert_eq!(channel_id.to_hex(), "0202020202020202020202020202020202020202020202020202020202020203"); | ||
| assert_eq!(channel_id.0.as_hex().to_string(), "0202020202020202020202020202020202020202020202020202020202020203"); | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not channel_id.to_string()?
| let our_node_id = SecretKey::from_slice(&hex::decode("2121212121212121212121212121212121212121212121212121212121212121").unwrap()[..]).unwrap(); | ||
| let our_ephemeral = SecretKey::from_slice(&hex::decode("2222222222222222222222222222222222222222222222222222222222222222").unwrap()[..]).unwrap(); | ||
| let our_node_id = SecretKey::from_slice(&<Vec<u8>>::from_hex("2121212121212121212121212121212121212121212121212121212121212121").unwrap()[..]).unwrap(); | ||
| let our_ephemeral = SecretKey::from_slice(&<Vec<u8>>::from_hex("2222222222222222222222222222222222222222222222222222222222222222").unwrap()[..]).unwrap(); | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like hex_lit::hex macro would help with these.
I tried to break up most of the changes into logical steps since there were so many things to fix, hopefully it helps.
A good follow-up to this would be to look into
ScriptBufuses that don't actually require the owned type.Fixes #2124.